Skip to content

fix(elixir_bytecode): fail the build on warnings with --warnings-as-errors - #4

Open
TrapsterDK wants to merge 1 commit into
bazelverse:mainfrom
TrapsterDK:pr3
Open

TrapsterDK wants to merge 1 commit into
bazelverse:mainfrom
TrapsterDK:pr3

Conversation

@TrapsterDK

Copy link
Copy Markdown

Problem
In released Elixir, elixirc --warnings-as-errors exits 0 when there are warnings. Kernel.CLI passes the option to Kernel.ParallelCompiler, which no longer reads it. This was checked with 1.20.4 and 1.19.5. test/BUILD.bazel already passes --warnings-as-errors to the basic app, but nothing checks that it fails, so this went unnoticed.

Elixir fixed it on main in de015a25d4 ("Fail elixirc on warnings with --warnings-as-errors"). That commit is not in a release yet.

Change

  • When --warnings-as-errors is in elixirc_opts, the ELIXIRC action captures stderr, prints it again, and fails if elixirc exited 0 but printed a warning: line. It prints Compilation failed due to warnings while using the --warnings-as-errors option, the same message as Mix and the fixed elixirc.
  • The launcher's own warning about a latin1 file name encoding (printed when the VM does not run with +fnu) is not a compiler warning and does not count. Without this exclusion, the basic app in test/ fails under --incompatible_strict_action_env.
  • When elixirc already fails, its status and output are kept unchanged. A compile error still fails with only Elixir's diagnostics. With an Elixir that contains de015a25d4, elixirc fails first and the check does nothing, so the message is not printed twice. The check can be removed once the supported Elixir versions all contain that fix.
  • bin/elixirc is still used. It execs elixir +elixirc.
  • set -x is removed. It wrote a trace of the elixirc command to stderr for every action, and Bazel printed it even when the build succeeded.

Test

  • test/warnings: three elixir_bytecode targets with --warnings-as-errors, tagged manual. They cover an unused variable, a call to an undefined function (reported after the module compiles), and IO.warn at compile time (printed without indentation).
  • A new CI step checks that each one fails and prints the message. It tests the status with if, because ! cmd does not stop a bash -e step. (The existing ! bazelisk test lines have the same issue: only the last one decides the step's status.)
  • //warnings:allowed compiles the unused-variable source without the option and builds as part of //....
  • On main, all three targets build successfully.

Test output (OTP 29.0, Elixir 1.20.3, Bazel 9.2.0, --nohome_rc)

bazel test //... in test/: Executed 1 out of 4 tests: 4 tests pass. The CI negative checks (failing_test, broken_test, empty_test) fail as expected. Each of //warnings:unused, //warnings:undef and //warnings:io_warn fails once with the message. The OTP 28.5 / Elixir 1.19.5 pair was not run as a whole.

Assisted by Claude.

…rrors

In released Elixir (checked with 1.19.5 and 1.20.4), elixirc accepts
--warnings-as-errors but exits 0 when there are warnings.
Kernel.CLI passes the option to Kernel.ParallelCompiler, which no
longer reads it. Elixir fixed this on main in de015a25d4 ("Fail
elixirc on warnings with --warnings-as-errors"), which is not in a
release yet.

When --warnings-as-errors is in elixirc_opts, capture elixirc's
stderr, print it again, and fail if elixirc exited 0 but printed a
warning, with the same message that Mix and fixed elixirc use. The
launcher's warning about a latin1 file name encoding is not a compiler
warning and does not count. When elixirc already fails, its own status
and output are kept, so with a fixed Elixir the check does nothing.

Also drop "set -x". It wrote a trace to stderr for every action, which
Bazel printed even when the build succeeded.

Tests: test/warnings has sources with an unused variable, a call to an
undefined function and an IO.warn at compile time, each compiled with
--warnings-as-errors. CI checks that each fails with the message. The
unused variable source without the option still builds in //....
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant